Robotic designs played an important role in recent advances by providing powerful robots with complex mechanics. Many recent systems rely on parallel actuation to provide lighter limbs and allow more complex motion. However, these emerging architectures fall outside the scope of most used description formats, leading to difficulties when designing, storing, and sharing the models of these systems. This paper introduces an extension to the widely used Unified Robot Description Format (URDF) to support closed-loop kinematic structures. Our approach relies on augmenting URDF with minimal additional information to allow more efficient modeling of complex robotic systems while maintaining compatibility with existing design and simulation frameworks. This method sets the basic requirement for a description format to handle parallel mechanisms efficiently. We demonstrate the applicability of our approach by providing an open-source collection of parallel robots, along with tools for generating and parsing this extended description format. The proposed extension simplifies robot modeling, reduces redundancy, and improves usability for advanced robotic applications.

Operations research (OR) uses mathematical models to enhance decision-making, but developing these models requires expert knowledge and can be time-consuming. Automated mathematical programming (AMP) has emerged to simplify this process, but existing systems have limitations. This paper introduces a novel methodology that uses recent advances in Large Language Model (LLM) to create and edit OR solutions from non-expert user queries expressed using Natural Language. This reduces the need for domain expertise and the time to formulate a problem. The paper presents an end-to-end pipeline, named NL2OR, that generates solutions to OR problems from natural language input, and shares experimental results on several important OR problems.

Among the thriving ecosystem of cloud computing and the proliferation of Large Language Model (LLM)-based code generation tools, there is a lack of benchmarking for code generation in cloud-native applications. In response to this need, we present CloudEval-YAML, a practical benchmark for cloud configuration generation. CloudEval-YAML tackles the diversity challenge by focusing on YAML, the de facto standard of numerous cloud-native tools. We develop the CloudEval-YAML benchmark with practicality in mind: the dataset consists of hand-written problems with unit tests targeting practical scenarios. We further enhanced the dataset to meet practical needs by rephrasing questions in a concise, abbreviated, and bilingual manner. The dataset consists of 1011 problems that take more than 1200 human hours to complete. To improve practicality during evaluation, we build a scalable evaluation platform for CloudEval-YAML that achieves a 20 times speedup over a single machine. To the best of our knowledge, the CloudEval-YAML dataset is the first hand-written dataset targeting cloud-native applications. We present an in-depth evaluation of 12 LLMs, leading to a deeper understanding of the problems and LLMs, as well as effective methods to improve task performance and reduce cost.

Cloud computing and the evolution of management methodologies such as Lean Management or Agile entail a profound transformation in both system construction and maintenance approaches. These practices are encompassed within the term "DevOps." This descriptive approach to an information system or application, alongside the configuration of its constituent components, has necessitated the development of descriptive languages paired with specialized engines for automating systems administration tasks. Among these, the tandem of Ansible (engine) and YAML (descriptive language) stands out as the two most prevalent tools in the market, facing notable competition mainly from Terraform. The current document presents an inquiry into a solution for generating and managing Ansible YAML roles and playbooks, utilizing Generative LLMs (Language Models) to translate human descriptions into code. Our efforts are focused on identifying plausible directions and outlining the potential industrial applications. Note: For the purpose of this experiment, we have opted against the use of Ansible Lightspeed. This is due to its reliance on an IBM Watson model, for which we have not found any publicly available references. Comprehensive information regarding this remarkable technology can be found [1] directly on our partner's website, RedHat.

As a data scientist, you are responsible for improving the model currently in production. After spending months fine-tuning the model, you discover one with greater accuracy than the original. Excited by your breakthrough, you create a pull request to merge your model into the main branch. Unfortunately, because of the numerous changes, your team takes over a week to evaluate and analyze them, which ultimately impedes project progress. Furthermore, after deploying the model, you identify unexpected behaviors resulting from code errors, causing the company to lose money.

Code repository for this post is here: you can see the MLFlow Recipes template in the main branch and the filled-in template on the fill-in-steps branch. The announcement of MLFlow 2.0 included a new framework called MLFlow Recipes. For a Data Scientists, using MLFlow Recipes means cloning a git repository, or "template", that comes with a ready-to-go folder structure for any regression or binary classification problem. This folder structure includes everything, from library requirements, configuration, notebooks and tests, that's needed to make a data science project reproducible and production-ready. It's easy to start a new project with MLFlow Recipes -- git clone a template from the MLFlow repository, and you are good to go.

My conviction for a product has never been so high for any ML Ops framework as for Ray. Let's be honest, most "ML Ops" libraries suck, not just suck they will probably slow down your ML scientists and data scientists vs not even using anything. Occasionally (surprisingly quite often now), someone asks me about ray and why I think is going to win. I spent plenty of hours trying to formalize my thoughts and here is a summary of it. In layman's terms, through a set of beautifully designed libraries and easy-to-use decorators (@ray.remote),

One of the biggest threats to productivity in recent times is context switching. It is a term originating from computer science but applied to humans it refers to the process of stopping work on one thing, performing a different task, and then picking back up the initial task. During a work day, you might want to check something on Stack Overflow, for example, which normalization technique to choose for your project. While doing so, you start exploring the documentation of scikit-learn to see which approaches are already implemented and how they compare against each other. This might lead to you some interesting comparison articles on Medium or video tutorials on YouTube.

When training a machine learning model or deploying it to an endpoint, you'll need to choose an appropriate machine to run it. I'll use the term "compute" to refer to the virtual machine (or set of machines) that runs your code in the cloud. The goal of this blog post is to give you an overview of all the compute options available to you in Azure ML, so that you can choose an appropriate option for your scenario. I'll assume that you're already familiar with the basic concepts of Azure ML, and that you have some experience using it for your own projects. Throughout this post, I'll discuss the following three major compute types available in Azure ML: I'll also briefly mention the available VM sizes, including how to get more quota for a particular VM size.

Originally published on Towards AI the World's Leading AI and Technology News and Media Company. If you are building an AI-related product or service, we invite you to consider becoming an AI sponsor. At Towards AI, we help scale AI and technology startups. Let us help you unleash your technology to the masses. If you want to analyze how fast 19 sparse BERT models perform inference, you'll only need a YAML file and 16GB of RAM to find out.